Queueing or message passing as a general concept is basic to many programming protocols. A list of objects is a convenient means of representing work requests between a client and a server. The server is responsible to remove a work object from the list, service the request, and send a response back to the client indicating that the service has been completed. The response may be presented to the client by placing a response object onto a list which is processed by the client. In such a client-server system, the server accepts and processes requests until all requests have been processed and the list of service requests is exhausted. Typically when the list of service requests is exhausted, the server enters a wait state or performs lower priority work until some form of notification is received indicating that additional requests have been placed on the list for service.
In multiprocessing and coupled systems environments, the lists of work objects and response objects are processed by a multiplicity of processes (programs), which may operate in one or more Central Processor Complexes (CPCs) comprising a multi-system configuration. The lists must be accessible by each of the processes, resulting in problems related to the coordination of activity between the several processes executing on separate CPCs.
These problems grow in environments where two or more CPCs are each remotely coupled to a shared external memory, or facility, containing queues of work and response objects. The delay and overhead involved in accessing the lists put a high premium on minimizing accesses to the external facility, as well as minimizing the direct interprocessor communication (messaging) required for coordination.
Exemplary of these problems is the problem of substantially reducing or eliminating remote requests by a process directed towards list objects which do not exist, that is, attempting to process list entries on a list which is empty. Processes which rely on "polling" techniques, which work well in local queueing environments where the costs of periodic polling are low, will suffer unacceptable performance penalties if polling must instead be done to an external facility for which a substantial likelihood exists that the list being polled is empty.
In order to reduce this overhead, techniques have been developed by which a remote client or server is notified when a queue becomes empty (so that polling can be suspended) or transitions from an empty to not-empty state (so that polling can be resumed). Typically such notification is done in static, or tightly controlled environments, where the association between the queue and the process interacting with the queue is known, so that the determination of which CPC to signal is simple. Additionally, such multi-systems must contend with the overhead within the multi-systems containing the client or server processes of being interrupted when such notifications are received, and handling the notification in an appropriately serialized manner if in fact the notification was broadcast to multiple CPCs to be executed in parallel by processes executing concurrently on those various systems. Such difficulties may severely restrict the operating environments which can accommodate such notification mechanisms.
Frey et al. (U.S. Pat. No. 5,390,328) teaches that these difficulties may be overcome using a mechanism in which the client and server processes register to be notified by the SES facility of state transitions (empty to not-empty, or not-empty to empty) involving particular lists in a SES facility list structure. Such notifications are sent by the SES facility to all users who have registered an interest in the particular list which experienced the transition, and only to such interested users, reducing the overhead inherent in undirected "broadcast" notification. Because these notifications do not interrupt the remote CPC to which the notification is directed, they cause little or no disruption to processes executing there; the notification signal changes the state of a particular bit in a "list notification vector" which resides in the Hardware System Area (HSA) of the remote CPC to reflect the empty or not-empty state of the list with which the vector bit has been associated by the remote user. In the case of an empty to not-empty list state transition, the notification signal may also set summary indicators associated with the vector so that the modification of some bit in the vector may be more efficiently observed.